Date: Tue, 8 Feb 94 04:30:01 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #36 To: tcp-group-digest TCP-Group Digest Tue, 8 Feb 94 Volume 94 : Issue 36 Today's Topics: Apology Can I attach (KA9Q) Net to Local Talk using Phonenet? Does exist Ethernet Driver for Net/Mac? (2 msgs) Mail Delivery Status param slottime & persist command - description? (2 msgs) PMNOS Some Questions About Basics WWW Ka9q Server?? (2 msgs) X.400 Distribution Status Report Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 7 Feb 94 11:56:35 PST From: koster@mdd.comm.mot.com (Ken Koster) Subject: Apology To: tcp-group@ucsd.edu My apologies to the group for the rash of old postings from 'gateway' recently. For approximately the last 3 years I've been redistributing this list to the local tcp/ip community via a local mailing list. Users have been able to subscribe to the list and respond back via my uucp connection 'algedi.data-io.com'. To the best of my knowledge we've never had a problem. Until now. :-( Due to a problem (as yet unknown) at one of the local stations at least 11 messages were resent to the list. I've temporarily disabled the ability for local users to respond until we can fix the problem. 73's, Ken N7IPB kenk@algedi.ampr.org ------------------------------ Date: Mon, 7 Feb 94 17:24 CDT From: emillar@enlaces.ufro.cl (Eduardo Millar) Subject: Can I attach (KA9Q) Net to Local Talk using Phonenet? To: tcp-group@ucsd.edu I have a Local Talk Network with Mac/TCP. We have connect the Local Talk Network with another TCP Network by radio-links. For radio-links we have used KA9Q package in PC. On the other hand I have Farallon Phonenet PC to connect a PC with Local Talk. My question is: Can I use the PC like Net/Router and connect this PC to Localtalk with Phonenet PC and using TCP/IP protocols?. I hope you anderstand to me. My English is not so good. -------------------------------------------------------------------------------- Eduardo Millar C. e-mail: emillar@enlaces.ufro.cl Area Telecomunicaciones Proyecto Enlaces Ufro-Mece Temuco- Chile -------------------------------------------------------------------------------- ------------------------------ Date: Mon, 7 Feb 94 11:12 CDT From: emillar@enlaces.ufro.cl (Eduardo Millar) Subject: Does exist Ethernet Driver for Net/Mac? To: tcp-group@ucsd.edu I have been used Net/Mac in a Local Talk network. The installations where I work, exist Ethernet Macintosh Network and I have to links this netwok with another Ethernet Macintosh Network by Radio. My question is: Anyone know a version of NetO/Mac that support any ethernet driver?.. ------------------------------ Date: Mon, 7 Feb 1994 10:31:23 -0900 From: dewayne@netcom.com (Dewayne Hendricks) Subject: Does exist Ethernet Driver for Net/Mac? To: emillar@enlaces.ufro.cl (Eduardo Millar), tcp-group@ucsd.edu At 11:12 2/7/94 -0500, Eduardo Millar wrote: >I have been used Net/Mac in a Local Talk network. The installations where >I work, exist Ethernet >Macintosh Network and I have to links this netwok with another Ethernet >Macintosh Network by Radio. My question is: Anyone know a version of >NetO/Mac that support any ethernet driver?.. NET/Mac does not support direct Ethernet connections. For instance, it cannot talk to MacTCP when it is configured via its control panel to use the Ethernet interface. NET/Mac does support EtherTalk, but not Ethernet. -- Dewayne -------------------------------------------------------------------------- Dewayne Hendricks, WA8DZP ! CIS: 75210,10 AppleLink: D6547 Tetherless Access Ltd. ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA.USA.NOAM 43730 Vista Del Mar ! AOL: HENDRICKS Fremont, CA 94539-3204 ! Internet: dewayne@netcom.com Phone: (510) 659-0809 ! Fax: (510) 770-9854 -------------------------------------------------------------------------- ------------------------------ Date: 07 Feb 1994 12:16:12 EST From: "Central Postmaster" Subject: Mail Delivery Status ***** Error in Mail Delivery ***** INVALID RECIPIENT Recipients: HARRIS.GPARKE04@IC1D.HARRIS.COM ------------------------------ Date: Mon, 7 Feb 1994 14:12:28 -0600 From: miltonm@inetnode.austin.ibm.com (Milton Miller) Subject: param slottime & persist command - description? To: gwillis@eleceng.adelaide.edu.au, tcp-group@ucsd.edu On Mon, 31 Jan 1994 03:24:45 +1030 (CST) in <199401301655.IAA00574@ucsd.edu>, gwillis@eleceng.adelaide.edu.au asked: > > Hello. > > I have been trying to find an accurate consise description of exactly > what the function of the 'persist' and 'slottime' functions are that > are set using the param command in NOS and how these parameters > affect radio channel performance. My understanding is that they are > a replacement for DWAIT which is found in many TNC software EPROMS. > P-Persist is a alternative channel access protocol that reduces the "everybody waiting starts transmitting at once" problem found in the DWAIT protocol. First, a short explanation of DWAIT: When a station has data to send, it first checks if the channel is busy. If so, then it waits until it clears, then keys and sends its data. The DWAIT protocol says it will wait y 10s of milliseconds for a digipeater to start transmitting before seizing the channel. For digipeated frames, the DWAIT time is bypassed, effectively giving priority to digipeated frames. Some of the problems incurred with this scheme are: (1) the digipeater has to check the crc, decide to send the data, and sieze the channel within the dwait window for it to gain any advantage (which isn't possible in KISS mode, because it has to go across the serial port to the host twice), and (2) As the channel becomes more crowded, the chances of having two stations waiting to send a packet increases. If their timeouts are the same length, they will continue to key on top of each other, resulting in a sequence of collisions. P-Persist instead relies on probabilities and random numbers to keep (2) from happening. When a station has data to send (be it new or digipeating information), it waits for the channel to clear. At that point, it picks a random number between 0 and 255. If it is less than or equal to the PERSISTance, it will sieze the channel and transmit. If not, it will wait SLOTTIME and then pick a new number if the channel is still free, repeating the process. As long as the numbers don't match, you won't continue to collide with the same station. Some MFJ firmware releases combine the two protocols by waiting for dwait before starting p-persist. Advice on choosing parameters: [I am sure someone will correct me if I have these wrong :-) I admit I haven't read the papers describing the studies.] The persistance plus 1 is divided by 256 to get the fraction of the time you will sieze the channel during any given slot. To avoid congestive collapse, it should be less than 1/(number of stations with data to transmit at any given time). Be sure to allow for more stations to come on your frequency, as it will run much better. But, as someone else pointed out, be facist about getting their parameters set right! (if they are too agressive, your station will kindly back off and wait for them to finish :-). For slot time, the time should be at least TXdelay, because that is supposedly how long it takes for a station to key up and have all the recievers recgonize the station being on the air. If all stations don't use the same slot time, then the back off doesn't help as much because the decision slots will not line up. If they are skewed far enough, a slot will appear as no activity even though another started in transmitting in the "previous" slot. Note this can still happen if the station decides it has data during the middle of an idle slot. [ brainstorm: this last issue could be addressed by requiring stations to wait for the channel to go busy and then idle before transmitting, unless the channel stays idle for some time >> slottime. Comments? ] > Could somebody point me in the direction of a document or file that > describes this function? Also which layer of the OSI protocol stack > do these functions belong to? (I am guessing level 1?) In addition to what I stated above, the Kantronics manual gives a reasonable description (although I don't remember any more information). Somewhere there have been a few papers written. > > Also I am interested to find out if there is any implementation of the > T2 timer described in the AX.25 v2.0 protcol specification in the > NOS package for AX.25 connections or IP virtual circuits carried on > AX.25? (This parameter is the equivalent of what in the popular TNCs > is seemingly called RESPTIME). Well, I guess that is the frame ack timers, but haven't looked at the source. I don't know the timers by their t number. > > Cheers de Grant VK5ZWI Hope this helps. I haven't seen any replies to the list, and I finally got a few minutes to type this in. milton -- Milton Miller KB5TKF miltonm@austin.ibm.com miltonm@bga.com I never speak for IBM. ------------------------------ Date: Mon, 7 Feb 1994 17:05:11 -0800 From: Phil Karn Subject: param slottime & persist command - description? To: miltonm@inetnode.austin.ibm.com >> Also I am interested to find out if there is any implementation of the >> T2 timer described in the AX.25 v2.0 protcol specification in the >> NOS package for AX.25 connections or IP virtual circuits carried on >> AX.25? (This parameter is the equivalent of what in the popular TNCs >> is seemingly called RESPTIME). >Well, I guess that is the frame ack timers, but haven't looked at the >source. I don't know the timers by their t number. These timers are optional in AX.25. If you run with MAXFRAME=1, then they don't do much since there's no point in waiting in case another frame gets sent before you ack the current one. Also, the round-robin scheduling in NOS usually (but not always) causes automatic piggybacking of the AX.25 ack on any data being sent in response to the AX.25 data. Phil ------------------------------ Date: Tue, 8 Feb 1994 09:04:08 GMT+1 From: Peter van der Post Subject: PMNOS To: tcp-group@ucsd.edu Hi everybody, For a period of three months I have the chance to get some experience with *real* E-mail, hi. Yesterday I took a subscription on this group and, wow, a reply from ucsd.edu in 30 seconds, I couldn't dream of such a quick response using packet radio, hi. Well to the point now. As an OS/2 user, I am a happy user of the Presentation Manager programs PMNOS en PMail by Walt Corey, KZ1F. It has been quite some time since I've heard or read from Walt. The latest news from Walt was that he had released version 1.1 of PMNOS. That was in the very beginning of 1993. Walt told us that he was working on something completely new, I guess, a Workplace Shell integrated version of the NOS en PMail functions/services. He mentioned the names WPNOS en WPMail some time. Together with a lot of other OS/2 users, I would very much like to know if Walt is still working on it. He made some promises about an SCC driver, which is at the top of my PMNOS wish list, hi. Well, thanks in advance for any replies, 73, Peter PE1NNH. ------------------------------ Date: Mon, 7 Feb 1994 14:39:32 -0600 From: miltonm@inetnode.austin.ibm.com (Milton Miller) Subject: Some Questions About Basics To: JSTEWART@umiami.ir.miami.edu, tcp-group@ucsd.edu On Sun, 30 Jan 1994 22:03:24 -0500 (EST), John Stewart asked: Disclaimer: I don't use packet drivers, so I will answer best guess. > I am trying to understand what interrupt buffers are used > for in NOS? Are they used on both transmit and receive? Only on receive (transmit buffers are allocated with interrupts enabled). > Given that ibufsize should be greater than or equal to MTU, > does the TCP WINDOW setting have an effect on the number of buffers > that you need? Yes, but it is your advertised recieve window, not your (maximum) send window. You need as many ibuf's as you expect packets from all hosts in your processing loop time. This should be at least the number of packets in a window (considering mss and mtu induced fragments). If you often have several connections activly sending data (ie multiple inbound ftps), you may need more. You can set it high for a while and see what minfree is, then lower it if it is excessive. > > Does the transmit queue length on the ATTACH PACKET statement > have an effect on the number of buffers that you need? I am not familiar with that parameter. > I have read the NOS documentation and some other references, but > am still missing part of the story. Can someone enlighten me? > > Thanks. > > John, n4qi > Internet: jstewart@umiami.ir.miami.edu > AmprNet: n4qi@n4qi.ampr.org milton -- Milton Miller KB5TKF miltonm@austin.ibm.com miltonm@bga.com I never speak for IBM. ------------------------------ Date: Mon, 7 Feb 1994 11:52:41 -0600 From: miltonm@inetnode.austin.ibm.com (Milton Miller) Subject: WWW Ka9q Server?? To: tcpgroup@ucsd.edu I found a tidbit in alt.winsock and followed up to get the following reference: Current supports .... searches (2 or 3 types) CSO database auto-index-file generation ascii and binary transfers IP based item access Here is the address of my Gopher / HTTP server gopher://biochemistry.bioc.cwru.edu/ or http://biochemistry.bioc.cwru.edu/ Regards, milton -- Milton Miller KB5TKF miltonm@austin.ibm.com miltonm@bga.com I never speak for IBM. ------------------------------ Date: Mon, 07 Feb 1994 20:40:27 -0500 From: ashok@biochemistry.cwru.edu (Ashok Aiyar) Subject: WWW Ka9q Server?? To: tcp-group@ucsd.edu > >I found a tidbit in alt.winsock and followed up to get the following >reference: > >Current supports .... >searches (2 or 3 types) >CSO database >auto-index-file generation >ascii and binary transfers >IP based item access > >Here is the address of my Gopher / HTTP server > >gopher://biochemistry.bioc.cwru.edu/ >or >http://biochemistry.bioc.cwru.edu/ > I had not intended to advertise it, but there is an excellent Gopher server for KA9Q. This is written by Chris McNeil of Mt. Allison Univ., Canada. In the post on alt.winsock, when I referred to my Gopher, I referred to the computer that I am running Chris' Gopher server on. Based on Chris' code, I do have a very crude HTTPD working on the same machine. That is the second thing referred to above. Later, Ashok -- Ashok Aiyar Mail: ashok@biochemistry.cwru.edu Department of Biochemistry Tel: (216) 368-3300 CWRU School of Medicine, Cleveland, Ohio Fax: (216) 368-4544 MIME Enclosures OK ------------------------------ Date: 07 Feb 1994 14:56:14 EST From: "X.400 Postmaster" Subject: X.400 Distribution Status Report To: TCP-Group@UCSD.EDU Soft-Switch X.400 Gateway Distribution Status Report 2/07/94 14:56:44 =============================================================================== Status: Unable to deliver mail as timeout occured while routing Subject: TCP-Group Digest Surname: GPARKE04 Country: US Admin. Domain: TELEMAIL Private Domain: HARRIS Organization: COMM Org Unit 1: HDD Org Unit 2: ENGRPOST ------------------------------ End of TCP-Group Digest V94 #36 ******************************